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BACKGROUND OF THE INVENTION 



Field of the Invention 

The invention described herein relates to information systems, and more 
particularly to delivery of multi-media content. 



Background Art 
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[0002] Given the availability of data networks and the availability of high-speed 

data connections, it is now commonplace for end users to access multi-media 
content. A number of web sites now offer audio and video to users. Ideally, the 
user simply clicks on a link or control presented in a web page, and one or more 
multi-media files are delivered. If the user has the appropriate hardware and 
software configuration, the file can then be played. 

[0003] There are currently a significant variety of user configurations, however. 

Some users have INTEL based personal computers (PCs), while others may have 
APPLE MACINTOSH computers. Different operating systems are also present. 
Some users will have a version MICROSOFT WINDOWS, from MICROSOFT, 
Inc., while others have a version of MAC OS, from APPLE, Inc. Moreover, each 
of these operating systems now has several versions in the user community. In 
addition, a number of software programs are now available to play multimedia on 
the computers of users. These players include QUICKTIME (from APPLE, Inc.), 
REALPLAYER (from REALNETWORKS, Inc.), and WINDOWS MEDIA 
PLAYER (from MICROSOFT, Inc.). Moreover, each of these players has several 
versions that are currently available in the user community. Finally, different 
users may be operating at different data rates. Some users may have a high speed 
broadband connection, while others may have a 56K modem connection. 

[0004] Given this variety of platforms, operating systems, players, and data rates, 

a content provider is faced with the problem of how to format the content to be 
delivered. Incorrect formatting would result in the delivery of content that was 
incompatible with a user's configuration. This could result in content that is 
unusable. If the content is usable, the content may be in a format that fails to take 
advantage of all the features available in the user's configuration, such that the 
content, as experienced by the user, is not as rich as it could be. 

[0005] In the past, content providers have addressed this problem by choosing 

some set of common user configurations. The provider, for example, might 
identify the most common media players and versions thereof. The provider 
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formats the content for each of these players and stores these assorted versions of 
the content. The provider would then develop a menu to be provided to the user, 
in effect asking which media player the user has, or, if the user has more than one, 
which player is preferred by the user. The user then makes a selection, and the 
content that has been pre-encoded in the selected format is delivered to the user. 

[0006] This solution has limitations. First, it is relatively inflexible. The number 

of options is limited. A user's specific configuration may not have been 
presented as an option in the menu. And if an end user has more than one media 
player available to him, the user's preferred choice may not have been listed as an 
option. Also, the solution above requires user input each time. The user might 
not want to be queried. The user may instead prefer that formatting be resolved 
for him. In other situations, the user might not know the information requested 
by the menu. The user may not know what version of a media player he has. 
This solution also requires that a content provider change their menus and re- 
encode content whenever new players (or new versions of existing players) 
become prevalent. The above solution, therefore, is inflexible and burdensome 
to both the user and the provider. 

[0007] What is needed, therefore, is a way to determine a user' s configuration so 

as to provide the user with content in a compatible format that leads to the 
optimal viewing experience. In addition, determination of the configuration 
should be made in a manner that minimizes the need for user input and is 
otherwise user-friendly. 

BRIEF SUMMARY OF THE INVENTION 

[0008] The invention described herein is a system, method, and computer 

program product for determining the configuration of an end user's computer 
system. In particular, the invention remotely determines the media players and 
network connection speed of the user. This configuration information is then 
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received by a delivery management server, and used in the formatting of multi- 
media content for delivery to the user. Because the content is formatted 
according to the configuration information, the content is compatible with the 
user's configuration, and moreover, is tailored to provide the user with the 
optimal multi-media experience. 
[0009] In an embodiment of the invention, the configuration determination 

process involves server contact code that is placed in the web page of the content 
provider. When the web page is loaded by the user, the server contact code 
directs the browser to retrieve scripts from the delivery management server. 
When the scripts are executed by the user, the media player of the user is 
determined. This information is saved in cookies at the user and is sent to the 
delivery management server. The configuration information can then be used by 
a transcoder that formats the media content according to the configuration 
information. 

[0010] If the configuration information is indeterminate or incomplete, the user 

is presented with a preferences page in which the user can indicate the 
configuration. This configuration, as determined through the preferences page, 
is also stored in cookies and sent to the delivery management server to allow 
formatting of content. The preferences page can also make specific 
recommendations to the user, e.g., recommend that the user choose a specific 
media player. 

[0011] In an embodiment of the invention, the preferences page also contains a 

mechanism for determining the connection speed of the user. The preferences 
page contains a block of data having a known size. The time required to transfer 
the block is measured, and the connection speed is then calculated and provided 
to the delivery management server. 

[0012] The foregoing and other features and advantages of the invention will be 

apparent from the following, more particular description of a preferred 
embodiment of the invention, as illustrated in the accompanying drawings. 
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BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES 

[0013] FIG. 1 illustrates the general architecture of an embodiment of the 

invention. 

[0014] FIG. 2 is a block diagram illustrating the computing environment of an 

embodiment of the invention. 
[0015] FIG. 3 is a flow chart illustrating the overall process of an embodiment of 

the invention. 

[0016] FIG. 4 is a flow chart illustrating the process of media player detection, 

according to an embodiment of the invention. 
[0017] FIG. 5 is a flow chart illustrating the process of presenting a preferences 

page to the user, according to an embodiment of the invention. 
[0018] FIG. 6 is a flow chart illustrating the process of setting cookies according 

to an embodiment of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

[0019] A preferred embodiment of the present invention is now described with 

reference to the figures, where like reference numbers indicate identical or 
functionally similar elements. Also in the figures, the left-most digit of each 
reference number corresponds to the figure in which the reference number is first 
used. While specific configurations and arrangements are discussed, it should be 
understood that this is done for illustrative purposes only. A person skilled in the 
relevant art will recognize that other configurations and arrangements can be used 
without departing from the spirit and scope of the invention. It will be apparent 
to a person skilled in the relevant art that this invention can also be employed in 
a variety of other devices and applications. 
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I. Overview 



[0020] The invention described herein is a system, method, and computer 

program product that allows the remote determination of a user's computer system 
configuration. This allows multimedia content destined for that computer to be 
formatted in a manner compatible with the user's configuration. If sufficient 
configuration information is obtained, the content can be formatted so as to 
provide the best possible media experience for the user. 

[0021] Note that in the description that follows, the concept of a user's computer 

is defined broadly to include the full range of programmable or programmed 
devices. A user's computer can be, but is not limited to, a personal computer or 
other workstation, a laptop, a palmtop, a personal data assistant, or a cell phone. 

[0022] In an embodiment of the invention, server contact code is contained in a 

web page sent by a content provider to the user. The server contact code retrieves 
one or more scripts from a delivery management server. The scripts enable the 
determination of configuration information of the user's computer system. In an 
embodiment of the invention, the configuration information comprises the 
identity and version of the user' s media player(s). The configuration information 
is then returned to the delivery management server. The configuration 
information can then be used to format the multi-media content appropriately. 
In an embodiment of the invention, configuration information is also stored 
locally at the user's computer in the form of cookies. In subsequent hypertext 
transfer protocol (HTTP) requests, the cookies can be sent to the delivery 
management server as a way of conveying the configuration information. 

[0023] If the configuration information is determined to be incomplete or 

potentially outdated, an additional web page is opened. This is a preferences 
page, where the user can specify his configuration (e.g. , his available or preferred 
media player type and version, and/or a preferred connection speed) to the 
delivery management server. The preferences page can also be used to 
recommend that the user choose a specific media player. 
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[0024] In an embodiment of the invention, the preferences page includes a block 

of data of known size. This block is transferred into the user's computer as a part 
of the preferences page. The time required to transfer this block of data is 
measured in order to determine the connection speed of the user's computer. The 
connection speed represents an additional piece of configuration information. 
The connection speed is also stored locally at the user's computer in the form of 
a cookie. This cookie can also be sent to the delivery management server as a 
way of conveying the user's connection rate to the delivery management server. 

n. System 

[0025] The overall architecture of the an embodiment of the invention includes 

server contact code embedded in a web page of a content provider. The server 
contact code directs the user's browser to a delivery management server, which 
sends one or more scripts to the user. Execution of the scripts can identify the 
type and version of the user's media player. This delivery management server 
receives this information from the user. The configuration information can 
eventually be used to format multi-media content for delivery to the user. 

[0026] One embodiment of the system of the invention is illustrated in FIG. 1. 

A content provider 105 is shown delivering information to a user 1 10. Included 
in web page 115 is server contact code 120. When the browser of user 110 
accesses server contact code 120, the browser establishes contact with delivery 
management server 125 and asks for one or more player detection scripts 140. 
Server 125 responds by sending scripts 140 to user 110. In a manner that will be 
described in greater detail below, the scripts 140, when executed, determine 
configuration information 135 for user 1 10. In an embodiment of the invention, 
this configuration information is stored with user 110 by a process of setting 
cookies that contain configuration information 135. The cookies are retained by 
user 1 10, and when user 1 10 makes the HTTP request 130 to access the content, 
configuration information 135, in the form of the cookies, is sent to delivery 



SKGF Ref. 1968.0030000 



-8- 

management server 125. A transcoder (not shown) formats the multi-media 
content in a manner specified by configuration information 135. The resulting 
formatted content can then be delivered to user 1 10 through a streaming server 
(not shown). 

[0027] If configuration information 135 is not available (or otherwise requires 

clarification), an additional script, provided to user 1 10 as one of the scripts 140, 
opens a new window that loads a preferences web page 150. With this page, user 
110 can explicitly identify configuration information 135 (e.g., the player type 
and version) through a user interface in preferences page 150. As before, the 
configuration information 135 can be retained at user 1 10 in the form of cookies 
and forwarded to delivery management server 125. 

[0028] In an embodiment of the invention, a recommendation can be made by the 

delivery management server to the user, through the preferences page 150, as to 
a particular media player that the user can or should select. Such a 
recommendation is based on what is known about the user's options. In such an 
embodiment of the preferences page 150, the recommendation can be conveyed 
through a portion of the page. This portion can be thought of as a server 
interface, since the server communicates to the user through this interface. 

[0029] As will be described in greater detail below, the preferences page includes 

a block of data 155 having a known size. The transfer of the block 155 is timed 
in order to determine the connection speed of the user 1 10. In an embodiment of 
the invention, block 155 (known hereinafter as the timing block) is incorporated 
in an HTML comment in the preferences page 150. 

[0030] In some contexts of the invention, the delivery management server 125 is 

one of a set of such servers. Here, the set of delivery management servers 
services a community of users by means of the invention described herein. Given 
a user's request for content, the user would be assigned to a specific delivery 
management server through a selection mechanism that balances the load created 
by multiple users. 
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[0031] In an embodiment of the invention, the functionality of delivery 

management server 125 is embodied in a viewer web server interface to a 
transcoding engine. The transcoding engine, in general, receives content from a 
content provider and formats ("transcodes") the content in a manner that makes 
it usable by user 110. The viewer web server interface is a network interface 
between the transcoding engine and the user 110, that allows content to be 
requested by user 1 10. The viewer web server interface receives and processes 
a content request from the user 110, thereby initiating the transcoding and 
delivery of the requested content to the user 110. The viewer web server 
interface sends a reply to user 110's request, redirecting the user 110 to an 
appropriate streaming server from which to receive the requested media content. 
Formatted ("transcoded") content is then streamed to the user 1 10 by a streaming 
server and/or proxy server (also a part of the transcoding engine). Such a 
transcoding engine is described in greater detail in U.S. Patent Application 
09/742,294, "Distributed On-Demand Media Transcoding System and Method," 
filed on December 22, 2000, and incorporated by reference herein in its entirety. 
Alternatively, the delivery management server 125 and the viewer web server 
interface can be implemented as separate servers. 

[0032] Note that the invention described herein can be implemented in a variety 

of organizational contexts. For example, the transcoding and delivery 
management operations described above can be performed by a delivery 
management service. This service may be, for example, a separate organization 
or business entity independent of the content provider 105. In this case, web 
page 115 may be developed by content provider 1 05 independently of the delivery 
management service. Web page 115 could then include a logo or other branding 
images, and/or a "look and feel" specific to content provider 105. Likewise, 
preferences page 150, though delivered to user 110 by delivery management 
server 125, could also be developed by content provider 105 independent of the 
delivery management service. 
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[0033] Independence of the delivery management service and content provider 

105 would also allow the delivery management service to make service changes 
on its own. The delivery management service would be free to upgrade its 
service by adding or otherwise modifying functionality. Player detection scripts 
140 could be improved, for example, so as to make the player detection process 
faster or more comprehensive, independent of a specific content provider 105. 
The transcoding process could also be upgraded independent of content provider 
105, to accommodate additional media formats or to provide faster transcoding, 
for example. 

[0034] The delivery management server 125 may be implemented using 

hardware, software or a combination thereof. In particular, server 125 may be 
implemented using a computer system or other processing system. An example 
of such a computer system 200 is shown in FIG. 2. The computer system 200 
includes one or more processors, such as processor 204. The processor 204 is 
connected to a communication infrastructure 206 (e.g., a bus or network). 
Various software embodiments can be described in terms of this exemplary 
computer system. After reading this description, it will become apparent to a 
person skilled in the relevant art how to implement the invention using other 
computer systems and/or computer architectures. 

[0035] Computer system 200 also includes a main memory 208, preferably 

random access memory (RAM), and may also include a secondary memory 210. 
The secondary memory 210 may include, for example, a hard disk drive 212 
and/or a removable storage drive 214, representing a magnetic tape drive, an 
optical disk drive, etc. The removable storage drive 214 reads from and/or writes 
to a removable storage unit 2 1 8 in a well known manner. Removable storage unit 
218 represents a magnetic tape, optical disk, etc. As will be appreciated, the 
removable storage unit 218 includes a computer usable storage medium having 
stored therein computer software and/or data. 
[0036] Secondary memory 210 can also include other similar means for allowing 

computer programs or input data to be loaded into computer system 200. Such 
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means may include, for example, a removable storage unit 222 and an interface 
220. Examples of such may include a program cartridge and cartridge interface 
(such as that found in video game devices), a removable memory chip (such as 
an EPROM, or PROM) and associated socket, and other removable storage units 
222 and interfaces 220 which allow software and data to be transferred from the 
removable storage unit 222 to computer system 200. 
[0037] Computer system 200 may also include a communications interface 224. 

Communications interface 224 allows software and data to be transferred between 
computer system 200 and external devices. Examples of communications 
interface 224 may include a modem, a network interface (such as an Ethernet 
card), a communications port, a PCMCIA slot and card, etc. Software and data 
transferred via communications interface 224 are in the form of signals 228 which 
may be electronic, electromagnetic, optical or other signals capable of being 
received by communications interface 224. These signals 228 are provided to 
communications interface 224 via a communications path (i.e., channel) 226. 
This channel 226 carries signals 228 into and out of computer system 200, and 
may be implemented using wire or cable, fiber optics, a phone line, a cellular 
phone link, an RF link and other communications channels. In an embodiment 
of the invention, signals 228 can convey information required by the delivery 
management server 125, such as HTTP request 130 and configuration 
information 135. Signals 228 can also convey information to user 1 10, such as 
scripts 140 and preferences page 150. 
[0038] In this document, the terms "computer program medium" and "computer 

usable medium" are used to generally refer to media such as removable storage 
drive 214, a hard disk installed in hard disk drive 212, and signals 228. These 
computer program products are means for providing software to computer system 
200. The invention is directed in part to such computer program products. 
[0039] Computer programs (also called computer control logic) are stored in 

main memory 208 and/or secondary memory 210. Computer programs may also 
be received via communications interface 224. Such computer programs, when 
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executed, enable the computer system 200 to perform the features of the present 
invention as discussed herein. In particular, the computer programs, when 
executed, enable the processor 204 to perform the features of the present 
invention. Accordingly, such computer programs represent controllers of the 
computer system 200. 

m. Method 

[0040] In the method of the invention, the configuration information of a user's 

computer is determined and sent to a delivery management server. The delivery 
management server then passes the configuration information to a transcoder that 
formats multi-media content according to the configuration information. The 
formatted content can then be sent to the user. 

[0041] The overall process of the invention is illustrated in FIG. 3. The process 

begins at step 305. In step 310, the user begins loading a web page of a content 
provider. As described in Section n, the web page contains server contact code 
which directs the user's browser to the delivery management server. In an 
embodiment of the invention, this is accomplished in an HTML header of the 
content provider's web page. For example, the HTML header could contain the 
following server contact code: 

[0042] 

<SCRIPT SRC="http://js.genericmedia.net/js" LANGUAGE=javascript></SRC> 

where " js.genericmedia.net" represents the delivery management server. 
[0043] In an embodiment of the invention, execution of the server contact code 

is initiated by an action of the user, such as clicking on a control or link in the 
content provider's web page, or by entering an explicit command. In an 
alternative embodiment, the server contact code is executed automatically after 
loading the web page. 
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[0044] In step 320, the user's browser fetches player detection code from the 

delivery management server ("js" in the example above). In step 325, the media 
players that can be used by the user are determined. This step will be described 
in greater detail below. In step 330, the identity of the media players is recorded 
in one or more cookies in the user's computer. This step will also be described 
in greater detail below. 

[0045] In conjunction with this step, a decision is made at the delivery 

management server (step 331) as to whether the received configuration 
information is sufficient to format the requested multi-media content. If cookies 
are received and verified as having valid settings, a minimal HTTP response is 
sent back, implying validity. If the received configuration information is 
sufficient to format the requested multi-media content, processing continues at 
step 335, described below. 

[0046] If js does not receive valid cookies (i.e., if configuration information at the 

user is insufficient or nonexistent), the method continues at step 332. In step 332 
a preferences page is displayed for the user. In an embodiment of the invention, 
this is accomplished by sending the user a segment of javascript that opens a new 
window which loads the preferences page. The preferences page allows the user 
to deliberately indicate to the delivery management server the configuration or 
preferences of the user with respect to the media player, and/or the user's 
connection speed. In an embodiment of the invention, the preferences page can 
also recommend to the user that a specific media player be chosen. Also, as will 
be described in greater detail below, the preferences page includes a mechanism 
through which the connection speed of the user's computer can be determined and 
relayed to the delivery management server. 

[0047] In step 333 , the preferences provided by the user are received by the user' s 

computer. In step 334, the preferences are stored in cookies. Processing then 
continues at step 335. 

[0048] In step 335, the user requests the multi-media content, made available by 

the content provider through a web page, by making an HTTP request. Such a 
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request can be made, for example, by clicking on some region of the content 
provider's web page. As a part of this request, any cookies that contain 
configuration information are sent to the delivery management server. The 
cookies could, for example, describe the media player type and version. The 
cookies could also store the measured connection speed, as well as any preferred 
connection speed that the user might have. The user may, for example, wish to 
use only a portion of the available bandwidth for streaming. Here, the user would 
choose a slower speed than the maximum permitted by the user's configuration. 
The process concludes at step 370. 

An example of an HTTP request ("GET") is as follows. Existing cookies 
(gmPlayers, gmPlayerPref, and gmBitratePref) are sent to the delivery 
management server as part of the GET command: 

GET /xc?p=keith&s=media/Trailer.mov&v=1 HTTP/1.1 

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms- 
powerpoint, application/vnd.ms-excel, application/msword, */* 

Accept-Language: en-us 

Accept-Encoding: gzip, deflate 

User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) 
Host: xc.genericmedia.net 
Connection: Keep-Alive 

Cookie:gmPlayers=vl%2F%2FQuickTime-4.12%2F%2FReal-6.0.7.788%2F%2FWMP- 
6.4%2F%2F; gmPlayerPref=real; gmBitratePref=300000 

The server uses the URL information and cookie information to decide to 
transcode the movie "media/Trailer.mov" (in user Keith's account) to a 300kbps 
encoding suited for RealPlayer G2: 

HTTP/1.1 200 OK 

Date: Mon, 16 Jul 2001 23:52:00 GMT 
Server: Apache/ 1 .3.14 (Unix) mod_perl/l .24 
Connection: close 
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Expires: Thu, 01 Dec 1994 16:00:00 GMT 

Pragma: no-cache, no-store, must-revalidate, no-transform 

Transfer-Encoding: chunked 

Content-Type: audio/x-pn-realaudio 

41 

rtsp://64.1 24.76.1 36:554/cache/Mlk3JeFIY0209200d7dn-a/Trailer.rm 
0 

[0050] Note that a user may be configured with more than one media player. If 

so, it may be unclear how to format the content, i.e., which player to choose. 
Moreover, the user may have a particular preference for one player over another. 
The preferences page provides a way to resolve these situations, by letting the 
user convey a player preference to the delivery management server. In an 
embodiment of the invention, the preferences page can convey a recommendation 
to the user as to which media player might provide the best results. 

[0051] There may also be cases where the above process fails to identify the 

user' s configuration with certainty. The player detection process may not be able 
to unambiguously ascertain the user's media player, for example, and the user 
might not know enough to answer the queries on the preferences page. In such 
cases, the delivery management server may make one or more inferences based 
on what is known about the user' s configuration. For example, if it is known that 
the user has a MACINTOSH platform, it can generally be assumed that 
QUICKTIME is available on the platform, since MACINTOSH computers are 
often equipped with QUICKTIME. Other such associations may also be used to 
infer configuration information that is otherwise unavailable. In an embodiment 
of the invention, confirmation of such an inference can be had by soliciting the 
user for confirmation, through the preferences page. 

[0052] Step 325 above, the step of performing player detection, is described in 

greater detail in FIG. 4. This process begins at step 405. In step 410, a 
determination is made as to what browser the user has. Typically, the user's 
browser will be either a version of NETSCAPE NAVIGATOR, or a version of 
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INTERNET EXPLORER (IE). If the user has NETSCAPE NAVIGATOR, then 
the process continues at step 411. In step 41 1, a string search for a given media 
player is performed through the resident mimetype array and plugin array. The 
mimetype array is a mapping of what application to load upon receiving a 
response with a given mimetype. Any given media player typically has its own 
mimetype. The plugin array is a listing of all browser plugins that have been 
installed; typically, each has registered a corresponding mimetype. As a result, 
these arrays will typically contain character strings that indicate the media 
player(s) resident on the user's computer. QUICKTIME is indicated by the string 
"QuickTime" for example, and WINDOWS MEDIA PLAYER is indicated by the 
string "video/x-msvideo". 

[0053] If in step 41 3 the string search is successful, then the player is determined 

to be present in step 415. Otherwise, processing continues at step 416. In step 
416 a determination is made as to whether another media player is to be sought. 
If so, processing returns to step 41 1, and a string search is conducted for another 
media player. In the illustrated embodiment, therefore, multiple string searches 
will generally be performed, although the invention can be implemented to 
perform a single search. The process concludes at step 417. 

[0054] Note that different versions of a given player may be registered with the 

browser using slightly different names or properties. Detection of these 
distinctions by string searches can provide information as to specific versions. 
In an embodiment of the invention, the string searches are implemented using 
javascript. 

[0055] If, in step 410, it is determined that the user's browser is INTERNET 

EXPLORER, then the process continues at step 420. Here, the browser is asked 
to instantiate an object for a given media player and version. In an embodiment 
of the invention, this instantiation is done using Vbscript. Creation of a 
REALPLAYER version 5 object, for example, would be attempted with the 
statement 
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CreateObject("RealPlayer.RealPlayer(tm) ActiveX Control (32-bit)". 

[0056] If, in step 425, this instantiation is permitted, this implies that the media 

player is in fact present on the user's computer, as shown in step 430. The 
process then continues at step 440. If, in step 425, instantiation of the given 
media player object is not permitted, then it can be assumed that the media player 
is not resident at the user's computer. In step 440, a determination is made as to 
whether the presence of any other media player should be ascertained. If so, the 
process returns to step 420 and another attempt will be made, this time to 
instantiate an object for a different media player. If, in step 440, a determination 
is made that no other media player will be sought, then the process concludes at 
step 417. Note that differences between players, especially differences between 
versions of a player, can be detected by corresponding differences in how player 
objects are instantiated in step 420. Also, for player objects that support version 
queries (e.g. , QUICKTIME and REALPLAYER), the player can be asked directly 
about its version. 

[0057] Step 355 above, the step of presenting a preferences page to the user, is 

illustrated in greater detail in FIG. 5 according to an embodiment of the invention. 
The process begins at step 505. In step 510, the preferences page is loaded from 
the delivery management server. In step 515, the transfer of a block of data of 
known size, stored within the preferences page, begins. The transfer of this block 
is timed to determine the user's connection speed. This block is denoted 
hereinafter as a timing block. In an embodiment of the invention, the timing 
block is included in the preferences page as an HTML comment. As a result the 
browser ignores the timing block for processing purposes. 

[0058] At the same time the transfer of the timing block begins, the browser notes 

the time at which the transferring of the timing block starts. In step 520, the 
transfer of the timing block concludes, and the time at which the transfer 
concludes is also noted by the browser. In step 530, a calculation is made as to 
the connection speed, i.e., data transfer rate, based on the time required to transfer 
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the timing block and on its known size. In step 535, loading of the preferences 
page concludes and the possible configurations that the user might have are 
displayed for the user. In step 540, the user's input with regards to the 
configuration is received. The process concludes at step 545. 
[0059] The preferences page can also be displayed at times other than what is 

described above with respect to FIG. 3. In an embodiment of the invention, the 
user is given a link in the content provider' s web page through which the user can 
access the preferences page whenever desired. This allows the user to change the 
stated preferences at will. In another embodiment of the invention, the 
preferences page is displayed to the user at regular intervals, e.g., every six 
months. This allows the user to make periodic updates of the configuration 
information. 

[0060] With respect to the setting of cookies , when a browser makes a request to 

a server, the browser only sends up cookies that are associated with the server's 
domain. A cookie can be associated with a new domain in one of two ways: 

1) a Set-Cookie: header is received from a server within the new domain, or 

2) the cookie is set via javascript by a page that was loaded from a server in the 
new domain. 

Since the player detection code is not always being run from a delivery 
management server page (e.g., the case where the player detection is loaded as 
part of the header of a content provider's web page), a way to set the cookies is 
needed. The goal is a third party cookie, whereby a cookie that would otherwise 
be set to the original domain (the content provider's domain) is set instead to the 
delivery management server's domain. In an embodiment of the invention, this 
can be done by making a dummy image() request from within javascript. Given 
a request that the image be loaded from the delivery management server's domain, 
the delivery management server can reply by sending back a Set-Cookie: header. 
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This can be applied in steps 330 and 334 above, and is illustrated in FIG. 
6. The process begins at step 605. In step 610 a URL is built at the user's 
computer directed to a cookie set script at the delivery management server. In 
step 615, a dummy image object is created at the user's computer. This object 
serves no purpose except to allow a dummy image request to be made, from 
within javascript, to the domain of the delivery management server. At step 620 
the browser makes an HTTP request, asking that a dummy image be loaded from 
the domain of the delivery management server; this request incorporates a request 
for the cookie set script. In step 625, the delivery management server responds 
by associating the cookies with the server (i.e., sending back a Set-Cookie: 
header). This will allow the cookies to be sent to the delivery management 
server, even though their presence at the user's computer may have originally 
been determined by the content provider or some other domain. In step 630, 
configuration information is stored in the cookies. The process concludes at step 
635. 

An example of such an exchange between a user and a delivery 
management server is illustrated below: 

GET /ssp/cookieset?gmPlayerPref=real HTTP/1.1 

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms- 
powerpoint, application/vnd.ms-excel, application/msword, */* 

Accept-Language: en-us 

Accept-Encoding: gzip, deflate 

User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) 
Host: js.genericmedia.net 
Connection: Keep-Alive 

Cookie:gmPlayers=vl%2F%2FQuickTime-4.12%2F%2FReal-6.0.7.788%2F%2 FWM P- 
6.4%2F%2F;gmPlayerPref=wmf; gmBitratePref=300000 

The server then responds: 

HTTP/ 1.1 200 OK 
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Date: Tue, 1 2 Jun 2001 20:08:29 GMT 
Server: Apache/ 1 .3.14 (Unix) mod_perl/l .24 

Set-Cookie:gmPlayers=vl%2F%2FQuickTime-4.12%2F%2FReal-6.0.7.788%2F%2 FWMP- 
6.4%2F%2F;domain=.genericmedia.net; path = /; expires=Mon, 10-Sep-2001 20:08:29 
GMT 

P3P: CP="1ND OUR PRE UNI ONL COM" 

Set-Cookie: gmPlayerPref=real; domain=.genericmedia.net; path=/;expires=Mon, 
10-Sep-2001 20:08:29 GMT 

Connection: close 

Cache-Control: no-cache, max-age=l 
Transfer-Encoding: chunked 
Content-Type: text/html 

IV. Conclusion 

[0063] While various embodiments of the present invention have been described 

above, it should be understood that they have been presented by way of example, 
and not limitation. It will be apparent to persons skilled in the relevant art that 
various changes in detail can be made therein without departing from the spirit 
and scope of the invention. Thus the present invention should not be limited by 
any of the above-described exemplary embodiments. 
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